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Path Computation Element Communication Protocol 
(PCEP) Extensions for Associated Bidirectional Label 
Switched Paths (LSPs) 


Abstract 


This document defines Path Computation Element Communication Protocol (PCEP) extensions 
for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in 
the network, into an associated bidirectional LSP. These PCEP extensions can be applied either 
using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The 
PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
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1. Introduction 


[RFC5440] describes the Path Computation Element Communication Protocol (PCEP) as a 
communication mechanism between a Path Computation Client (PCC) and a Path Computation 
Element (PCE), or between PCE and PCC, that enables computation of Multiprotocol Label 
Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths (LSPs). 


[RFC8231] specifies extensions to PCEP to enable stateful control of MPLS-TE LSPs. It describes 
two modes of operation: passive stateful PCE and active stateful PCE. In [RFC8231], the focus is on 
active stateful PCE where LSPs are provisioned on the PCC and control over them is delegated to 
a PCE. Further, [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs 
for the stateful PCE model. 
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[RFC8697] introduces a generic mechanism for creating a grouping of LSPs. This grouping can 
then be used to define associations between sets of LSPs or between a set of LSPs and a set of 
attributes, and it is equally applicable to the stateful PCE (active and passive modes) and the 
stateless PCE. 


The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that "MPLS- 
TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to- 
point transport paths". [RFC7551] defines RSVP signaling extensions for binding forward and 
reverse unidirectional LSPs into an associated bidirectional LSP. The fast reroute (FRR) 
procedures for associated bidirectional LSPs are described in [RFC8537]. 


This document defines PCEP extensions for grouping two unidirectional MPLS-TE LSPs into an 
associated bidirectional LSP for both single-sided and double-sided initiation cases either when 
using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or when using a stateless PCE. 
The procedures defined are applicable to the LSPs using Resource Reservation Protocol - Traffic 
Engineering (RSVP-TE) for signaling [RFC3209]. Specifically, this document defines two new 
Association Types, Single-Sided Bidirectional LSP Association and Double-Sided Bidirectional LSP 
Association, as well as the Bidirectional LSP Association Group TLV, to carry additional 
information for the association. 


The procedure for associating two unidirectional Segment Routing (SR) paths to form an 
associated bidirectional SR path is defined in [BIDIR-PATH] and is outside the scope of this 
document. 


2. Conventions Used in This Document 


2.1. Key Word Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2.2. Terminology 


The reader is assumed to be familiar with the terminology defined in [RFC5440], [RFC7551], 
[RFC8231], and [RFC8697]. 


3. Overview 


As shown in Figure 1, forward and reverse unidirectional LSPs can be grouped to form an 
associated bidirectional LSP. Node A is the ingress node for LSP1 and egress node for LSP2, 
whereas node D is the ingress node for LSP2 and egress node for LSP1. There are two methods of 
initiating the Bidirectional LSP Association, single-sided and double-sided, as defined in 
[RFC7551] and described in the following sections. 
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LSPi) ==> ESP --> SPs > 
+----- + +----- + +----- + +----- + 
IATE + B +----------- + C +----------- + D 
+----- + +--+--+ +--+--+ +----- + 
< LSP2 | | <-- LSP2 
| | 
| | 
+--+--+ +--+--+ 
| 1B sreporeeciaeae ap |e | 
+----- + +----- + 
<-- LSP2 


Figure 1: Example of Associated Bidirectional LSP 


3.1. Single-Sided Initiation 


As specified in [RFC7551], in the single-sided case, the bidirectional tunnel is provisioned only on 
one endpoint node (PCC) of the tunnel. Both endpoint nodes act as PCCs. Both forward and 
reverse LSPs of this tunnel are initiated with the Association Type set to "Single-Sided 
Bidirectional LSP Association" on the originating endpoint node. The forward and reverse LSPs 
are identified in the Bidirectional LSP Association Group TLV of their PCEP ASSOCIATION objects. 


The originating endpoint node signals the properties for the reverse LSP in the RSVP 
REVERSE_LSP object [RFC7551] of the forward LSP Path message. The remote endpoint node then 
creates the corresponding reverse tunnel and reverse LSP, and it then signals the reverse LSP in 
response to the received RSVP-TE Path message. Similarly, the remote endpoint node deletes the 
reverse LSP when it receives the RSVP-TE message to delete the forward LSP [RFC3209]. 


As specified in [RFC8537], for fast reroute bypass tunnel assignment, the LSP starting from the 
originating endpoint node is identified as the forward LSP of the single-sided initiated 
bidirectional LSP. 
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3.1.1. PCE-Initiated Single-Sided Bidirectional LSP 


Legend: F 


+----- + 
I PCE] 
+----- + 
Initiates: | \ 
Tunnel 1 (F) l \ 
(LSP1 (F, @), LSP2 (R, @)) | \ 
Association #1 v \ 
+----- + + 
| A | | 
+----- + + 
+----- + 
| PCE: | 
+----- + 
Reports: À a 
Tunnel 1 (F) l \ 
(LSP1 (F, P1), LSP2 (R, P2)) | \ 
Association #1 | \ 
+----- + + 
EEA | 
+----- + + 


Forward LSP, R = Reverse LSP 


Reports: 
Tunnel 2 (F) 
(LSP2 (F, P3)) 
Association #1 


, (8,P1,P2,P3) = PLSP-IDs 


Figure 2: Example of PCE-Initiated Single-Sided Bidirectional LSP 


Using partial topology from Figure 1, as shown in Figure 2, the forward Tunnel 1 and both 
forward LSP1 and reverse LSP2 are initiated on the originating endpoint node A by the PCE. The 
PCEP-specific LSP identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint node A 
and P3 on the remote endpoint node D. The originating endpoint node A reports Tunnel 1 and 
forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 
to the PCE. 
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3.1.2. PCC-Initiated Single-Sided Bidirectional LSP 


+----- + 
| PCE] 
+----- + 
Reports/Delegates: A Reports: 


(LSP1 (F, P1), LSP2 (R, P2)) \ (LSP2 (F, P3)) 


A 
Tunnel 1 (F) l \ Tunnel 2 (F) 
| 
Association #2 | \ Association #2 


Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs 
Figure 3: Example of PCC-Initiated Single-Sided Bidirectional LSP 


Using partial topology from Figure 1, as shown in Figure 3, the forward Tunnel 1 and both 
forward LSP1 and reverse LSP2 are initiated on the originating endpoint node A (the originating 
PCC). The PLSP-IDs used are P1 and P2 on the originating endpoint node A and P3 on the remote 
endpoint node D. The originating endpoint (PCC) node A may delegate the forward LSP1 and 
reverse LSP2 to the PCE. The originating endpoint node A reports Tunnel 1 and forward LSP1 
and reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the PCE. 


3.2. Double-Sided Initiation 


As specified in [RFC7551], in the double-sided case, the bidirectional tunnel is provisioned on 
both endpoint nodes (PCCs) of the tunnel. The forward and reverse LSPs of this tunnel are 
initiated with the Association Type set to "Double-Sided Bidirectional LSP Association" on both 
endpoint nodes. The forward and reverse LSPs are identified in the Bidirectional LSP Association 
Group TLV of their ASSOCIATION objects. 


As specified in [RFC8537], for fast reroute bypass tunnel assignment, the LSP with the higher 
source address [RFC3209] is identified as the forward LSP of the double-sided initiated 
bidirectional LSP. 
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3.2.1. PCE-Initiated Double-Sided Bidirectional LSP 


Initiates: 
Tunnel 1 (F) 
(LSP1 (F, @)) 
Association #3 


Reports: 
Tunnel 1 (F) 
(LSP1 (F, P4)) 
Association #3 


Legend: F = Forward LSP, 


+----- + 
[PECET] 
+----- + 

\ Initiates: 

\ Tunnel 2 (F) 


\ (LSP2 (F, @)) 


Association #3 
----- + +-----+ 
A | 
----- + +-----+ 
+----- + 
| ee | 
+----- + 
A Reports: 
Tunnel 2 (F) 


\ (LSP2 (F, P5)) 
\ Association #3 


(0,P4,P5) = PLSP-IDs 


Figure 4: Example of PCE-Initiated Double-Sided Bidirectional LSP 


Using partial topology from Figure 1, as shown in Figure 4, the forward Tunnel 1 and forward 
LSP1 are initiated on the endpoint node A, and the reverse Tunnel 2 and reverse LSP2 are 
initiated on the endpoint node D by the PCE. The PLSP-IDs used are P4 on the endpoint node A 
and P5 on the endpoint node D. The endpoint node A (PCC) reports the forward LSP1, and 
endpoint node D reports the forward LSP2 to the PCE. 


3.2.2. PCC-Initiated Double-Sided Bidirectional LSP 


Reports/Delegates: 
Tunnel 1 (F) 

(LSP1 (F, P4)) 
Association #4 


+----- + 
RECES| 
+----- + 
A Reports/Delegates: 
Tunnel 2 (F) 


Ñ (LSP2 (F P5)) 
Ñ Association #4 


+----- + +----- + 
| A ED l 
+----- + +----- + 

Legend: F = Forward LSP, (P4,P5) = PLSP-IDs 


Figure 5: Example of PCC-Initiated Double-Sided Bidirectional LSP 


Gandhi, et al. 


Standards Track Page 8 


RFC 9059 PCEP for Associated Bidirectional LSPs June 2021 


Using partial topology from Figure 1, as shown in Figure 5, the forward Tunnel 1 and forward 
LSP1 are initiated on the endpoint node A, and the reverse Tunnel 2 and reverse LSP2 are 
initiated on the endpoint node D (the PCCs). The PLSP-IDs used are P4 on the endpoint node A 
and P5 on the endpoint node D. Both endpoint (PCC) nodes may delegate the forward LSP1 and 
LSP2 to the PCE. The endpoint node A (PCC) reports the forward LSP1, and endpoint node D 
reports the forward LSP2 to the PCE. 


3.3. Co-routed Associated Bidirectional LSP 


In both single-sided and double-sided initiation cases, forward and reverse LSPs can be co-routed 
as shown in Figure 6, where both forward and reverse LSPs of a bidirectional LSP follow the 
same congruent path in the forward and reverse directions, respectively. 


LSP3 ==> USPI ==> LSP3 --> 
+----- + +----- + +----- + +----- + 
| VA toss oon + B +----------- + C +----------- TEEDE] 
+----- + +----- + +----- + +----- + 
<-- LSP4 <-- LSP4 <-- LSP4 


Figure 6: Example of Co-routed Associated Bidirectional LSP 


The procedure specified in [RFC8537] for fast reroute bypass tunnel assignment is also applicable 
to the co-routed associated bidirectional LSPs. 


3.4. Summary of PCEP Extensions 


The PCEP extensions defined in this document cover the following modes of operation under the 
stateful PCE model: 


e A PCC initiates the forward and reverse LSP of a single-sided bidirectional LSP and retains 
control of the LSPs. Similarly, both PCCs initiate the forward LSPs of a double-sided 
bidirectional LSP and retain control of the LSPs. The PCC computes the path itself or makes a 
request for path computation to a PCE. After the path setup, it reports the information and 
state of the path to the PCE. This includes the association group identifying the bidirectional 
LSP. This is the passive stateful mode defined in [RFC8051]. 


e A PCC initiates the forward and reverse LSP of a single-sided bidirectional LSP and delegates 
control of the LSPs to a stateful PCE. Similarly, both PCCs initiate the forward LSPs of a 
double-sided bidirectional LSP and delegate control of the LSPs to a stateful PCE. During 
delegation, the association group identifying the bidirectional LSP is included. The PCE 
computes the path of the LSP and updates the PCC with the information about the path as 
long as it controls the LSP. This is the active stateful mode defined in [RFC8051]. 

e A PCE initiates the forward and reverse LSP of a single-sided bidirectional LSP on a PCC and 
retains control of the LSP. Similarly, a PCE initiates the forward LSPs of a double-sided 
bidirectional LSP on both PCCs and retains control of the LSPs. The PCE is responsible for 
computing the path of the LSP and updating the PCC with the information about the path as 
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well as the association group identifying the bidirectional LSP. This is the PCE-initiated mode 
defined in [RFC8281]. 


e A PCC requests co-routed or non-co-routed paths for forward and reverse LSPs of a 
bidirectional LSP, including when using a stateless PCE [RFC5440]. 


3.5. Operational Considerations 


The double-sided case has an advantage when compared to the single-sided case, summarized as 
follows: 


e In the double-sided case, two existing unidirectional LSPs in reverse directions in the 
network can be associated to form a bidirectional LSP without significantly increasing the 
operational complexity. 


The single-sided case has some advantages when compared to the double-sided case, 
summarized as follows: 


e Some Operations, Administration, and Maintenance (OAM) use cases may require an 
endpoint node to know both forward and reverse paths for monitoring the bidirectional LSP. 
For such use cases, the single-sided case may be preferred. 


e For co-routed associated bidirectional LSPs in PCC-initiated mode, the single-sided case 
allows the originating PCC to dynamically compute co-routed forward and reverse paths. 
This may not be possible with the double-sided case where the forward and reverse paths 
are computed separately as triggered by two different PCCs. 

e The associated bidirectional LSPs in the single-sided case can be deployed in a network 
where PCEP is only enabled on the originating endpoint nodes as remote endpoint nodes 
create the reverse tunnels using RSVP-TE Path messages. 


4. Protocol Extensions 


4.1. ASSOCIATION Object 


As per [RFC8697], LSPs are associated by adding them to a common association group. This 
document defines two new Association Types, called "Single-Sided Bidirectional LSP Association" 
(4) and "Double-Sided Bidirectional LSP Association" (5), using the generic ASSOCIATION object 
(Object-Class value 40). A member of the Bidirectional LSP Association can take the role of a 
forward or reverse LSP and follows the following rules: 


e An LSP (forward or reverse) MUST NOT be part of more than one Bidirectional LSP 
Association. 

e The LSPs in a Bidirectional LSP Association MUST have matching endpoint nodes in the 
reverse directions. 

e The same tunnel (as defined in Section 2.1 of [RFC3209]) MUST contain the forward and 
reverse LSPs of the Single-Sided Bidirectional LSP Association on the originating node, albeit 
both LSPs have reversed endpoint nodes. 
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The Bidirectional LSP Association Types are considered to be both dynamic and operator 
configured in nature. As per [RFC8697], the association group could be manually created by the 
operator on the PCEP peers, and the LSPs belonging to this association are conveyed via PCEP 
messages to the PCEP peer; alternately, the association group could be created dynamically by 
the PCEP speaker, and both the association group information and the LSPs belonging to the 
association group are conveyed to the PCEP peer. The operator-configured Association Range 
MUST be set for this Association Type to mark a range of Association Identifiers that are used for 
operator-configured associations to avoid any Association Identifier clash within the scope of the 
Association Source (refer to [RFC8697]). 


Specifically, for the PCE-initiated bidirectional LSPs, these associations are dynamically created 
by the PCE on the PCE peers. Similarly, for both the PCE-initiated and the PCC-initiated single- 
sided cases, these associations are also dynamically created on the remote endpoint node using 
the information received from the RSVP message from the originating node. 


The Association ID, Association Source, optional Global Association Source TLV, and optional 
Extended Association ID TLV in the Bidirectional LSP ASSOCIATION object are initialized using 
the procedures defined in [RFC8697] and [RFC7551]. 


[RFC8697] specifies the mechanism for the capability advertisement of the Association Types 
supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN 
object. This capability exchange for the Bidirectional LSP Association Types MUST be done before 
using the Bidirectional LSP Association. Thus, the PCEP speaker MUST include the Bidirectional 
LSP Association Types in the ASSOC-Type-List TLV and MUST receive the same from the PCEP 
peer before using the Bidirectional LSP Association in PCEP messages. 


4.2. Bidirectional LSP Association Group TLV 


The Bidirectional LSP Association Group TLV is an OPTIONAL TLV for use with Bidirectional LSP 
Associations (ASSOCIATION object with Association Type 4 for Single-Sided Bidirectional LSP 
Association or 5 for Double-Sided Bidirectional LSP Association). 


e The Bidirectional LSP Association Group TLV follows the PCEP TLV format from [RFC5440]. 

e The Type (16 bits) of the TLV is 54. 

e The Length is 4 bytes. 

° The value comprises of a single field, the Flags field (32 bits), where each bit represents a flag 
option. 

e If the Bidirectional LSP Association Group TLV is missing, it means the LSP is the forward 
LSP, and it is not a co-routed LSP. 


e When the Bidirectional LSP Association Group TLV is present, the R flag MUST be reset for 
the forward LSP for both co-routed and non-co-routed LSPs. 


e For co-routed LSPs, this TLV MUST be present and the C flag set. 
e For reverse LSPs, this TLV MUST be present and the R flag set. 
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e The Bidirectional LSP Association Group TLV MUST NOT be present more than once. If it 
appears more than once, only the first occurrence is processed, and any others MUST be 
ignored. 


The format of the Bidirectional LSP Association Group TLV is shown in Figure 7. 


Q 1 2 3 
Q1°2):3° 4-5 6) 7 8) 9 GI 273° 45 6 7-8) 996 123) 4°5 6 7 8°98 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type = 54 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Flags ICIR] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 7: Bidirectional LSP Association Group TLV Format 


Flags for the Bidirectional LSP Association Group TLV are defined as follows. 


R (Reverse LSP, 1 bit, bit number 31): Indicates whether the LSP associated is the reverse LSP of 
the bidirectional LSP. If this flag is set, the LSP is a reverse LSP. If this flag is not set, the LSP is 
a forward LSP. 


C (Co-routed Path, 1 bit, bit number 30): Indicates whether the bidirectional LSP is co-routed. 
This flag MUST be set for both the forward and reverse LSPs of a co-routed bidirectional LSP. 


The C flag is used by the PCE (both stateful and stateless) to compute bidirectional paths of the 
forward and reverse LSPs of a co-routed bidirectional LSP. 


The unassigned flags (bit numbers 0-29) MUST be set to 0 when sent and MUST be ignored when 
received. 


5. PCEP Procedure 


The PCEP procedure defined in this document is applicable to the following three scenarios: 


e Neither unidirectional LSP exists, and both must be established. 
e Both unidirectional LSPs exist, but the association must be established. 
e One LSP exists, but the reverse associated LSP must be established. 


5.1. PCE-Initiated LSPs 


As specified in [RFC8697], Bidirectional LSP Associations can be created and updated by a 
stateful PCE. 


e For a Single-Sided Bidirectional LSP Association initiated by the PCE, the PCE MUST send a 
PCInitiate message to the originating endpoint node with both forward and reverse LSPs. For 
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a Double-Sided Bidirectional LSP Association initiated by the PCE, it MUST send a PCInitiate 
message to both endpoint nodes with forward LSPs. 

e Both PCCs MUST report the forward and reverse LSPs in the Bidirectional LSP Association to 
the PCE. A PCC reports via a PCRpt message. 

e Stateful PCEs MAY create and update the forward and reverse LSPs independently for the 
Single-Sided Bidirectional LSP Association on the originating endpoint node. 

e Stateful PCEs MAY create and update the forward LSP independently for the Double-Sided 
Bidirectional LSP Association on the endpoint nodes. 

e Stateful PCEs establish and remove the association relationship on a per-LSP basis. 

e Stateful PCEs create and update the LSP and the association on PCCs via PCInitiate and 
PCUpd messages, respectively, using the procedures described in [RFC8697]. 


5.2. PCC-Initiated LSPs 


As specified in [RFC8697], Bidirectional LSP Associations can also be created and updated by a 
PCC. 


e For a Single-Sided Bidirectional LSP Association initiated at a PCC, the PCC MUST send a 
PCRpt message to the PCE with both forward and reverse LSPs. For a Double-Sided 
Bidirectional LSP Association initiated at the PCCs, both PCCs MUST send a PCRpt message to 
the PCE with forward LSPs. 

e PCCs on the originating endpoint node MAY create and update the forward and reverse LSPs 
independently for the Single-Sided Bidirectional LSP Association. 

e PCCs on the endpoint nodes MAY create and update the forward LSP independently for the 
Double-Sided Bidirectional LSP Association. 

e PCCs establish and remove the association group on a per-LSP basis. PCCs MUST report the 
change in the association group of an LSP to PCE(s) via a PCRpt message. 

e PCCs report the forward and reverse LSPs in the Bidirectional LSP Association independently 
to PCE(s) via a PCRpt message. 

e PCCs for the single-sided case MAY delegate the forward and reverse LSPs independently to a 
stateful PCE, where the PCE would control the LSPs. In this case, the originating (PCC) 
endpoint node SHOULD delegate both forward and reverse LSPs of a tunnel together to a 
stateful PCE in order to avoid any race condition. 

e PCCs for the double-sided case MAY delegate the forward LSPs to a stateful PCE, where the 
PCE would control the LSPs. 

e A stateful PCE updates the LSPs in the Bidirectional LSP Association via a PCUpd message, 
using the procedures described in [RFC8697]. 


5.3. Stateless PCE 


For a stateless PCE, it might be useful to associate a path computation request to an association 
group, thus enabling it to associate a common set of configuration parameters or behaviors with 
the request [RFC8697]. A PCC can request co-routed or non-co-routed forward and reverse paths 
from a stateless PCE for a Bidirectional LSP Association. 
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5.4. Bidirectional (B) Flag 


As defined in [RFC5440], the Bidirectional (B) flag in the Request Parameters (RP) object is set 
when the PCC specifies that the path computation request is for a bidirectional TE LSP with the 
same TE requirements in each direction. For an associated bidirectional LSP, the B flag is also set 
when the PCC makes the path computation request for the same TE requirements for the 
forward and reverse LSPs. 


Note that the B flag defined in a Stateful PCE Request Parameter (SRP) object [STATEFUL-PCE- 
GMPLS] to indicate "bidirectional co-routed LSP" is used for GMPLS-signaled bidirectional LSPs 
and is not applicable to the associated bidirectional LSPs. 


5.5. PLSP-ID Usage 


As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is created by a PCC to uniquely 
identify an LSP, and it remains the same for the lifetime of a PCEP session. 


In the case of a Single-Sided Bidirectional LSP Association, the reverse LSP of a bidirectional LSP 
created on the originating endpoint node is identified by the PCE using two different PLSP-IDs, 
based on the PCEP session on the ingress or egress node PCCs for the LSP. In other words, the LSP 
will have a PLSP-ID P2 allocated at the ingress node PCC, while it will have a PLSP-ID P3 allocated 
at the egress node PCC (as shown in Figures 2 and 3). There is no change in the PLSP-ID allocation 
procedure for the forward LSP of a single-sided bidirectional LSP created on the originating 
endpoint node. 


In the case of a Double-Sided Bidirectional LSP Association, there is no change in the PLSP-ID 
allocation procedure for the forward LSPs on either PCC. 


For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV [RFC8231] MUST be included in all 
forward and reverse LSPs. 


5.6. State Synchronization 


During state synchronization, a PCC MUST report all the existing Bidirectional LSP Associations to 
the stateful PCE, as per [RFC8697]. After the state synchronization, the PCE MUST remove all 
previous Bidirectional LSP Associations absent in the report. 


5.7. Error Handling 


If a PCE speaker receives an LSP with a Bidirectional LSP Association Type that it does not 
support, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error- 
value = 1 (Association Type is not supported). 


An LSP (forward or reverse) cannot be part of more than one Bidirectional LSP Association. If a 
PCE speaker receives an LSP not complying to this rule, the PCE speaker MUST send PCErr with 
Error-Type = 26 (Association Error) and Error-value = 14 (Association group mismatch). 
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The LSPs (forward or reverse) in a Single-Sided Bidirectional Association MUST belong to the 
same TE tunnel (as defined in [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- 
Sided Bidirectional LSP Association for a different tunnel, the PCE speaker MUST send PCErr with 
Error-Type = 26 (Association Error) and Error-value = 15 (Tunnel mismatch in the association 
group). 


The PCEP Path Setup Type (PST) for RSVP-TE is set to "Path is set up using the RSVP-TE signaling 
protocol" (Value 0) [RFC8408]. If a PCEP speaker receives a different PST value for the 
Bidirectional LSP Associations defined in this document, the PCE speaker MUST return a PCErr 
message with Error-Type = 26 (Association Error) and Error-value = 16 (Path Setup Type not 
supported). 


A Bidirectional LSP Association cannot have both unidirectional LSPs identified as reverse LSPs 
or both LSPs identified as forward LSPs. If a PCE speaker receives an LSP not complying to this 
rule, the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value 
= 17 (Bidirectional LSP direction mismatch). 


A Bidirectional LSP Association cannot have one unidirectional LSP identified as co-routed and 
the other identified as non-co-routed. If a PCE speaker receives an LSP not complying to this rule, 
the PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 18 
(Bidirectional LSP co-routed mismatch). 


The unidirectional LSPs forming the Bidirectional LSP Association MUST have matching endpoint 
nodes in the reverse directions. If a PCE speaker receives an LSP not complying to this rule, the 
PCE speaker MUST send PCErr with Error-Type = 26 (Association Error) and Error-value = 19 
(Endpoint mismatch in the association group). 


The processing rules as specified in Section 6.4 of [RFC8697] continue to apply to the Association 
Types defined in this document. 


6. Security Considerations 


The security considerations described in [RFC5440], [RFC8231], and [RFC8281] apply to the 
extensions defined in this document as well. 


Two new Association Types for the ASSOCIATION object, Single-Sided Bidirectional LSP 
Association and Double-Sided Bidirectional LSP Association, are introduced in this document. 
Additional security considerations related to LSP associations due to a malicious PCEP speaker 
are described in [RFC8697] and apply to these Association Types. Hence, securing the PCEP 
session using Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. 


7. Manageability Considerations 


7.1. Control of Function and Policy 


The mechanisms defined in this document do not imply any control or policy requirements in 
addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 
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7.2. Information and Data Models 
[RFC7420] describes the PCEP MIB; there are no new MIB objects defined for LSP associations. 


The PCEP YANG module [PCE-PCEP-YANG] defines a data model for LSP associations. 


7.3. Liveness Detection and Monitoring 


The mechanisms defined in this document do not imply any new liveness detection and 
monitoring requirements in addition to those already listed in [RFC5440], [RFC8231], and 
[RFC8281]. 


7.4. Verify Correct Operations 


The mechanisms defined in this document do not imply any new operation verification 
requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 


7.5. Requirements on Other Protocols 


The mechanisms defined in this document do not add any new requirements on other protocols. 


7.6. Impact on Network Operations 


The mechanisms defined in this document do not have any impact on network operations in 
addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 


8. IANA Considerations 


8.1. Association Types 


This document defines two new Association Types [RFC8697]. IANA has assigned the following 
new values in the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 
Computation Element Protocol (PCEP) Numbers" registry: 


Type Name Reference 
4 Single-Sided Bidirectional LSP Association RFC 9059 
5 Double-Sided Bidirectional LSP Association RFC 9059 


Table 1: Additions to ASSOCIATION Type Field Subregistry 
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8.2. Bidirectional LSP Association Group TLV 


This document defines a new TLV for carrying additional information about LSPs within a 
Bidirectional LSP Association. IANA has assigned the following value in the "PCEP TLV Type 
Indicators" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" 
registry: 


Value Meaning Reference 


54 Bidirectional LSP Association Group TLV RFC 9059 
Table 2: Addition to PCEP TLV Type Indicators Subregistry 


8.2.1. Flag Field in Bidirectional LSP Association Group TLV 


IANA has created a new subregistry, named "Bidirectional LSP Association Group TLV Flag Field", 
within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag 
field in the Bidirectional LSP Association Group TLV. New values are assigned by Standards 
Action [RFC8126]. Each bit should be tracked with the following qualities: 


¢ Bit number (count from 0 as the most significant bit) 
e Description 
e Reference 


The initial contents of this registry are as follows: 


Bit Description Reference 
0-29 Unassigned 
30 C-Co-routed Path RFC 9059 


31 R - Reverse LSP RFC 9059 


Table 3: New Bidirectional LSP Association 
Group TLV Flag Field Subregistry 


8.3. PCEP Errors 


This document defines new Error-values for Error-Type 26 (Association Error). IANA has 
allocated the following new Error-values within the "PCEP-ERROR Object Error Types and 
Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: 


Error- Meaning Error-value Reference 

Type 

26 Association 14: Association group mismatch RFC 9059 
Error 
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Meaning Error-value Reference 
15: Tunnel mismatch in the association RFC 9059 
group 
16: Path Setup Type not supported RFC 9059 
17: Bidirectional LSP direction mismatch RFC 9059 
18: Bidirectional LSP co-routed mismatch RFC 9059 
19: Endpoint mismatch in the association RFC 9059 
group 


Table 4: Additions to PCEP-ERROR Object Error Types and Values Subregistry 
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